Tox testimise automatiseerimine: põhjalik ülevaade mitmekeskkonna testimisest globaalsetele meeskondadele

Tänapäeva globaalses tarkvaramaastikus on fraas "see töötab minu masinas" enam kui arendaja klišee; see on oluline äri risk. Teie kasutajad, kliendid ja koostööpartnerid on laiali üle kogu maailma, kasutades erinevaid operatsioonisüsteeme, Pythoni versioone ja sõltuvuspakette. Kuidas saate tagada, et teie kood ei ole mitte ainult funktsionaalne, vaid usaldusväärselt robustne kõigile ja kõikjal?

Vastus peitub süstemaatilises, automatiseeritud, mitmekeskkonna testimises. Siin muutub Tox, käsurealt juhitav automatiseerimistööriist, kaasaegse Pythoni arendaja tööriistakomplekti asendamatuks osaks. See standardiseerib testimise, võimaldades teil määratleda ja teostada teste mitmete konfiguratsioonide maatriksis ühe käsuga.

See põhjalik juhend viib teid Toxi põhitõdedest edasijõudnud strateegiateni mitmekeskkonna testimiseks. Uurime, kuidas ehitada vastupidav testimistoru, mis tagab, et teie tarkvara on ühilduv, stabiilne ja valmis globaalseks publikuks.

Mis on mitmekeskkonna testimine ja miks on see kriitiline?

Mitmekeskkonna testimine on teie testimiskomplekti käivitamine mitmete erinevate konfiguratsioonide vastu. Need konfiguratsioonid ehk "keskkonnad" erinevad tavaliselt järgmiste osas:

• Pythoni interpreteerijate versioonid: Kas teie kood töötab Python 3.8-s sama hästi kui Python 3.11-s? Aga tulevane Python 3.12?
• Sõltuvuste versioonid: Teie rakendus võib tugineda sellistele teekidele nagu Django, Pandas või Requests. Kas see katkeb, kui kasutajal on nende pakettide veidi vanem või uuem versioon?
• Operatsioonisüsteemid: Kas teie kood käsitleb failiteid ja süsteemikõnesid õigesti Windowsis, macOS-is ja Linuxis?
• Arhitektuurid: ARM-põhiste protsessorite (nt Apple Silicon) tõusuga muutub erinevatel CPU-arhitektuuridel (x86_64, arm64) testimine üha olulisemaks.

Ärijuhtum mitmekeskkonna strateegia jaoks

Seda tüüpi testimise seadistamisele aja investeerimine ei ole ainult akadeemiline harjutus; sellel on otsene mõju ärile:

• Vähendab tugikulusid: Ühilduvusprobleeme varakult avastades väldite tugipiletite tulva kasutajatelt, kelle keskkonda te polnud ette näinud.
• Suurendab kasutajate usaldust: Tarkvara, mis töötab usaldusväärselt erinevates seadistustes, tajutakse kõrgema kvaliteediga. See on ühtviisi oluline nii avatud lähtekoodiga teekide kui ka äriliste toodete puhul.
• Võimaldab sujuvamaid uuendusi: Kui ilmub uus Pythoni versioon, saate selle lihtsalt oma testimismaatriksisse lisada. Kui testid õnnestuvad, teate, et olete selle toetamiseks valmis. Kui need ebaõnnestuvad, on teil selge, tegutsemiseks valmis nimekiri sellest, mis vajab parandamist.
• Toetab globaalseid meeskondi: See tagab, et arendaja ühes riigis, kes kasutab uusimaid tööriistu, saab tõhusalt koostööd teha meeskonnaga teises piirkonnas, kus võib olla standardiseeritud, veidi vanem ettevõtte stack.

Toxi tutvustus: teie automatiseerimise juhtimiskeskus

Tox on loodud selle probleemi elegantseks lahendamiseks. Tox automatiseerib põhimõtteliselt isoleeritud Pythoni virtuaalsete keskkondade loomise, paigaldab sinna teie projekti ja selle sõltuvused ning seejärel käivitab teie määratletud käsud (nt testid, linterid või dokumentatsiooni ehitused).

Kõike seda juhib üks lihtne konfiguratsioonifail: tox.ini.

Alustamine: paigaldamine ja põhikonfiguratsioon

Paigaldamine on pipiga lihtne:

pip install tox

Järgmisena looge oma projekti juurkataloogi fail tox.ini. Alustame minimaalse konfiguratsiooniga, et testida mitme Pythoni versiooni vastu.

Näide: põhiline tox.ini

[tox]
min_version = 3.7
isolated_build = true
envlist = py38, py39, py310, py311

[testenv]
description = Run the main test suite
deps = pytest
commands = pytest

Lähme seda lahti:

• [tox] sektsioon: See on globaalsete Toxi sätete jaoks.
• min_version: määrab selle konfiguratsiooni käitamiseks vajaliku Toxi miinimumversiooni.
• isolated_build: kaasaegne parim tava (PEP 517), mis tagab, et teie pakett ehitatakse isoleeritud keskkonnas enne testimiseks installimist.
• envlist: see on mitmekeskkonna testimise süda. See on komadega eraldatud loetelu keskkondadest, mida soovite, et Tox haldaks. Siin oleme määratlenud neli: üks iga Pythoni versiooni jaoks alates 3.8-st kuni 3.11-ni.
• [testenv] sektsioon: See on mall kõigi envlistis määratletud keskkondade jaoks.
• description: kasulik teade, mis selgitab, mida keskkond teeb.
• deps: loetelu sõltuvustest, mis on teie käskude käitamiseks vajalikud. Siin vajame lihtsalt pytest.
• commands: käsud, mida virtuaalses keskkonnas täita. Siin me lihtsalt käivitame pytest testijooksu.

Selle käivitamiseks navigeerige oma projekti juurkataloogi oma terminalis ja tippige lihtsalt:

tox

Tox teeb nüüd järgmised sammud iga keskkonna jaoks envlistis (py38, py39 jne):

1. Otsige teie süsteemis vastavat Pythoni interpretaatorit (nt python3.8, python3.9).
2. Looge uus, isoleeritud virtuaalne keskkond kataloogi .tox/ sisse.
3. Installige oma projekt ja sõltuvused, mis on loetletud jaotises deps.
4. Teostage käsud, mis on loetletud jaotises commands.

Kui mõni samm mõnes keskkonnas ebaõnnestub, annab Tox veast teada ja väljub nullist erineva olekukoodiga, muutes selle ideaalseks pideva integratsiooni (CI) süsteemide jaoks.

Põhjalik: võimsa tox.ini koostamine

Põhiseadistus on võimas, kuid Toxi tõeline maagia peitub selle paindlikes konfiguratsioonivalikutes keerukate testimismaatriksite loomiseks.

Generatiivsed keskkonnad: kombinatoorse testimise võti

Kujutage ette, et teil on teek, mis peab toetama Django versioone 3.2 ja 4.2, mis jooksevad Python 3.9 ja 3.10 peal. Kõigi nelja kombinatsiooni käsitsi määratlemine oleks korduv:

Korduv viis: envlist = py39-django32, py39-django42, py310-django32, py310-django42

Tox pakub palju puhtamat, generatiivset süntaksit, kasutades lokkis sulgusid {}:

Generatiivne viis: envlist = {py39,py310}-django{32,42}

See üks rida laieneb samadeks neljaks keskkonnaks. See lähenemine on väga skaleeritav. Uue Pythoni versiooni või Django versiooni lisamine on vaid ühe üksuse lisamine vastavasse loendisse.

Faktor-tingimuslikud sätted: iga keskkonna kohandamine

Nüüd, kui oleme oma maatriksi määratlenud, kuidas me ütleme Toxile, et ta installiks õige Django versiooni igasse keskkonda? See on tehtud faktor-tingimuslike sätetega.

[tox]
envlist = {py39,py310}-django{32,42}

[testenv]
deps =
    pytest
    django32: Django>=3.2,<3.3
    django42: Django>=4.2,<4.3
commands = pytest

Siin ütleb rida `django32: Django>=3.2,<3.3` Toxile: "Kaasake see sõltuvus ainult siis, kui keskkonna nimi sisaldab faktorit `django32`." Samamoodi ka `django42` puhul. Tox on piisavalt nutikas, et parsida keskkonna nimed (nt `py310-django42`) ja rakendada õigeid sätteid.

See on uskumatult võimas funktsioon järgmiste haldamiseks:

• Sõltuvused, mis ei ühildu vanemate/uuemate Pythoni versioonidega.
• Testimine põhiteegi erinevate versioonide vastu (Pandas, NumPy, SQLAlchemy jne).
• Platvormispetsiifiliste sõltuvuste tingimuslik paigaldamine.

Oma projekti struktureerimine peale põhikatseid

Tugev kvaliteedikava hõlmab enamat kui lihtsalt testide käitamist. Samuti peate käivitama linterid, tüübikontrollid ja dokumentatsiooni koostama. See on parim tava määrata nende ülesannete jaoks eraldi Toxi keskkonnad.

[tox]
envlist = py{39,310}, lint, typing, docs

[testenv]
deps = pytest
commands = pytest

[testenv:lint]
description = Run linters (ruff, black)
basepython = python3.10
deps =
    ruff
    black
commands =
    ruff check .
    black --check .

[testenv:typing]
description = Run static type checker (mypy)
basepython = python3.10
deps =
    mypy
    # also include other dependencies with type hints
    django
    djangorestframework
commands = mypy my_project/

[testenv:docs]
description = Build the documentation
basepython = python3.10
deps = sphinx
commands = sphinx-build -b html docs/source docs/build/html

Siin on, mis on uut:

• Spetsiifilised keskkonna sektsioonid: Oleme lisanud `[testenv:lint]`, `[testenv:typing]` ja `[testenv:docs]`. Need jaotised määravad konkreetselt nende nimetatud keskkondade sätted, tühistades jaotise `[testenv]` vaikeseaded.
• basepython: Mittetestkeskkondade (nt `lint` või `docs`) puhul ei pea me neid sageli igal Pythoni versioonil käivitama. basepython võimaldab meil neid konkreetse interpretaatori külge siduda, muutes need kiiremaks ja deterministlikumaks.
• Puhas eraldamine: See struktuur hoiab teie sõltuvused puhtana. Keskkond `lint` installib ainult lintersid; teie peamised testimiskeskkonnad neid ei vaja.

Nüüd saate käitada kõiki keskkondi käsuga `tox`, konkreetset komplekti käsuga `tox -e py310,lint` või ainult ühte käsuga `tox -e docs`.

Toxi integreerimine CI/CD-ga globaalses mastaabis automatiseerimiseks

Toxi lokaalselt käitamine on suurepärane, kuid selle tõeline jõud vabaneb siis, kui see on integreeritud pideva integratsiooni/pideva juurutuse (CI/CD) torujuhtmesse. See tagab, et iga koodimuudatust valideeritakse automaatselt teie täieliku testimismaatriksiga.

Sellised teenused nagu GitHub Actions, GitLab CI ja Jenkins sobivad selleks suurepäraselt. Need võivad teie töökohti käivitada erinevatel operatsioonisüsteemidel, võimaldades teil luua põhjaliku OS-i ühilduvusmaatriksi.

Näide: GitHub Actionsi töövoog

Loome GitHub Actionsi töövoo, mis käivitab meie Toxi keskkonnad paralleelselt Linuxis, macOS-is ja Windowsis.

Looge fail aadressil .github/workflows/ci.yml:

name: CI

on: [push, pull_request]

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
        python-version: ['3.8', '3.9', '3.10', '3.11']

    steps:
    - name: Check out repository
      uses: actions/checkout@v3

    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v4
      with:
        python-version: ${{ matrix.python-version }}

    - name: Install Tox
      run: pip install tox tox-gh-actions

    - name: Run Tox
      run: tox -e py

Analüüsime seda töövoogu:

• strategy.matrix: See on meie CI maatriksi tuum. GitHub Actions loob iga kombinatsiooni jaoks eraldi töö `os` ja `python-version`. Selle konfiguratsiooni puhul on see 3 operatsioonisüsteemi × 4 Pythoni versiooni = 12 paralleelset töökohta.
• actions/setup-python@v4: See standardne toiming seab iga töö jaoks vajaliku konkreetse Pythoni versiooni.
• tox-gh-actions: See on kasulik Toxi plugin, mis kaardistab automaatselt CI keskkonna Pythoni versiooni õigele Toxi keskkonnale. Näiteks tööl, mis töötab Python 3.9-s, lahendab `tox -e py` automaatselt käivitamise `tox -e py39`. See säästab teid CI skriptis keeruka loogika kirjutamisest.

Nüüd, iga koodi surumisel, viiakse teie kogu testimismaatriks automaatselt läbi kõigis kolmes suuremas operatsioonisüsteemis. Saate kohese tagasiside selle kohta, kas muudatus on toonud kaasa kokkusobimatuse, võimaldades teil enesekindlalt luua globaalse kasutajabaasi jaoks.

Täiustatud strateegiad ja parimad tavad

Argumentide edastamine käskudele koos {posargs}-ga

Mõnikord peate oma testijooksujale edastama lisaparameetreid. Näiteks võiksite käivitada konkreetse testifaili: pytest tests/test_api.py. Tox toetab seda asendusega {posargs}.

Muutke oma faili `tox.ini`:

[testenv]
deps = pytest
commands = pytest {posargs}

Nüüd saate Toxi käivitada nii:

tox -e py310 -- -k "test_login" -v

-- eraldab Toxile mõeldud argumendid käsu jaoks mõeldud argumentidest. Kõik pärast seda asendatakse {posargs}-ga. Tox teostab: pytest -k "test_login" -v keskkonnas `py310`.

Keskkonnamuutujaid kontrollimine

Teie rakendus võib käituda erinevalt sõltuvalt keskkonnamuutujatest (nt DJANGO_SETTINGS_MODULE). Direktiiv setenv võimaldab teil neid oma Toxi keskkondades kontrollida.

[testenv]
setenv =
    PYTHONPATH = .
    MYAPP_MODE = testing

[testenv:docs]
setenv =
    SPHINX_BUILD = 1

Nõuanded kiiremate Toxi käivituste jaoks

Kui teie maatriks kasvab, võivad Toxi käivitused aeglaseks muutuda. Siin on mõned näpunäited nende kiirendamiseks:

• Paralleelrežiim: Käivitage tox -p auto, et Tox saaks teie keskkondi paralleelselt käitada, kasutades saadaolevate CPU-tuumade arvu. See on kaasaegsetel masinatel väga tõhus.
• Keskkondade selektiivne taasloomine: Vaikimisi kasutab Tox keskkondi uuesti. Kui teie sõltuvused failis `tox.ini` või `requirements.txt` muutuvad, peate Toxile ütlema, et ta ehitaks keskkonna uuesti nullist. Kasutage taasloomise lippu: tox -r -e py310.
• CI vahemällu salvestamine: Salvestage oma CI/CD torujuhtmes kataloog .tox/ vahemällu. See võib oluliselt kiirendada järgnevaid käivitusi, kuna sõltuvusi ei pea iga kord alla laadima ja installima, välja arvatud juhul, kui need muutuvad.

Globaalsed kasutusjuhud praktikas

Võtame arvesse, kuidas see kehtib erinevat tüüpi projektide puhul globaalses kontekstis.

1. stsenaarium: avatud lähtekoodiga andmeanalüüsi teek

Te haldate populaarset teeki, mis on ehitatud Pandase ja NumPy baasil. Teie kasutajad on andmeteadlased ja analüütikud kogu maailmas.

• Väljakutse: peate toetama mitut Pythoni, Pandase, NumPy versiooni ja tagama, et see töötab Linuxi serverites, macOS-i sülearvutites ja Windowsi lauaarvutites.
• Toxi lahendus: envlist = {py39,py310,py311}-{pandas1,pandas2}-{numpy18,numpy19} Teie `tox.ini` kasutaks faktor-tingimuslikke sätteid õigete teekide versioonide installimiseks igasse keskkonda. Teie GitHub Actionsi töövoog testiks seda maatriksit kõigis kolmes suuremas operatsioonisüsteemis. See tagab, et kasutaja Brasiilias, kes kasutab vanemat Pandase versiooni, saab sama usaldusväärse kogemuse kui Jaapanis, kes kasutab uusimat komplekti.

2. stsenaarium: ettevõtte SaaS-i rakendus koos klienditeegiga

Teie Euroopas peakorteriga ettevõte pakub SaaS-i toodet. Teie kliendid on suured, globaalsed ettevõtted, kellest paljud kasutavad stabiilsuse tagamiseks vanemaid, pikaajalise toega (LTS) operatsioonisüsteemide ja Pythoni versioone.

• Väljakutse: Teie arendusmeeskond kasutab kaasaegseid tööriistu, kuid teie klienditeek peab olema tagasi ühilduv vanemate ettevõtte keskkondadega.
• Toxi lahendus: envlist = py38, py39, py310, py311 Teie `tox.ini` tagab, et kõik testid läbivad Python 3.8-ga, mis võib olla standardiks suuremal kliendil Põhja-Ameerikas. Seda automaatselt CI-s käivitades takistate arendajatel kogemata tutvustamast funktsioone, mis kasutavad süntaksit või teeke, mis on saadaval ainult uuemates Pythoni versioonides, vältides kulukaid juurutamisvigu.

Järeldus: saatke globaalse kindlusega

Mitmekeskkonna testimine ei ole enam luksus; see on kõrge kvaliteediga professionaalse tarkvara arendamise põhipraktika. Toxiga automatiseerimist kasutusele võttes muundate selle keeruka väljakutse sujuvaks, korratavaks protsessiks.

Määrates oma toetatud keskkonnad ühes failis tox.ini ja integreerides selle CI/CD torujuhtmega, loote võimsa kvaliteedi värava. See värav tagab, et teie rakendus on tugev, ühilduv ja valmis mitmekesisele globaalsele publikule. Saate lõpetada muretsemise kardetud probleemi "see töötab minu masinas" pärast ja hakata koodi saatma kindlusega, et see töötab kõigi masinas, olenemata sellest, kus nad maailmas on.